Software programs use libraries as reusable program modules. These libraries may be the source of faults (e.g., crashes and bugs). Libraries may be dynamically linked with the software program. For example, a loading process is performed where application code (e.g., executables) from the software program is loaded into memory. Libraries that may be called by the application code are also loaded and dynamically linked with the application code. The dynamic linking process uses a procedure linkage table (PLT) that indirectly jumps from a fixed virtual address to the dynamic address where the library functions are located in memory.
When the application code needs to call a library function, the procedure linkage table is used to account for the dynamic location of the library function. For example, the dynamic linker modifies the PLT (or a separate Global Offset Table) with the final virtual address of each procedure that can be invoked in each loaded library. The program then jumps into the PLT entry for a library function from a call site in the application code. While executing instructions from the library function, a fault may occur. When the fault occurs, a way to safely recover from the fault may not be provided, which can result in a crash of the entire program. Also, for debugging purposes, there may not be a way to determine the call site from which the library function was entered.
In other examples, the call site may be determined using existing techniques. For example, the functions “setjmp” and “longjmp” (in C, or similar instructions in other programming languages) may be used to store a current execution state in thread local storage for a thread that is being used by a process executing the application code. The setjmp function saves the environment of the calling function into a data structure. The longjmp function can then use this structure to jump back to the call site of the calling function. The longjmp function allows the program to jump out of a number of function calls to the call site.
In order to use setjmp to store the environment of the calling function, additional code must be executed prior to each library function call. This code may be included prior to each call site, or it may be present in a wrapper function. Each library function is associated with a separate wrapper function, each of which requires distinct binary code in the software program. The wrapper requires multiple parameters that are not known at the time of coding, and thus have to be looked up by the wrapper function during runtime. For example, a thread-specific location in which the setjmp execution state is to be stored, and an address of the library function are not known. Thread local storage is looked up using an operating system specific method, and the library function address is stored in a separate data table.
This wrapper function adds an extra level of indirection due to the function call. Local variables are typically required for storing the address of thread local data, or for the parameter passed to setjmp. The wrapper requires its own stack frame for these local variables, and this stack frame is distinct from the frame which the program code at the call site constructed with its parameters for the library call itself. Having a separate stack frame, the wrapper must copy all arguments from the previous frame to the next. This adds a layer of indirection in the software program, amounting to one extra copy of each parameter and one extra function call. Also, the setjmp function may be able to save information in thread local storage for the call site. However, every register is saved, which saves additional information other than what is needed to determine the call site. Although the setjmp function and thread local storage may be used to determine the call site, these functions are considered slower function calls and also add overhead due to the high number of additional instructions that must be executed for each library call.
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.